InterCD 2001 October/october_2001.iso/Site Building/Atomix Buttons/DATA1.CAB/Program_Executable_Files/smartj.txt

Text File | 2000-02-14 | 13.0 KB | 285 lines

SmartJ Java launcher, version 0.51, 25 June 1999

author: Jonathan Revusky, [e-mail]

SmartJ.exe and SmartJW.exe are optional replacements for the
command-line java launchers java.exe and javaw.exe which come with Sun
Microsystems' JRE and JDK.

SmartJC.exe provides a front-end the JDK java compiler javac.exe or the
super-fast jikes compiler from IBM (separately downloadable DLL).

The difference is that the SmartJ utilities are designed to be much more
newbie friendly. SmartJ.exe is a console-mode launcher, while SmartJW is
the GUI launcher that, when associated with the .class extension, makes
.class files double-clickable in the Windows Explorer

(See the bottom of this file for the licence and conditions of use.)

History

This is version 0.51, released on June 25, 1999.
Version 0.50 was released on March 6, 1999.
Version 0.44 was released on January 13, 1999
Version 0.43 was released on December 18, 1998.
Version 0.42 was released on December 13, 1998.
Version 0.41 was released on December 9, 1998.
Version 0.40 was released on December 6, 1998.
Version 0.31 was released on August 1, 1998.
Version 0.30 was released on July 29, 1998.
Version 0.20 was released July 27, 1998.
Version 0.11 was released on July 24, 1998.


Improvements and changes in Version 0.51

Probably the biggest change going from Version 0.50 to version 0.51 is
that the default is now to launch Java 1.2 if it is available. So, if you have
both Java 1.2 and 1.1 runtime(s) installed, and you want to test using
a 1.1 runtime, you go: smartj -1 <classfile>

The next biggest change is that smartj now works with hotspot. It didn't
before. It also supports the -classic command-line option, which specifies
that hotspot should NOT be used.

Also, for my fellow JPython fans, I have included a SmartJP
executable which launches JPython. It snoops a bit to find your
JPython install directory, basically assuming that you did the sane thing
of putting it on a top-level directory that matches the pattern JPython*
on one of your hard drives. If you want to bury your Jpython in a
subdirectory or put it in a directory that's name does not start with JPython,
you need to set the environment variable JPYTHON_HOME to where the
jpython home directory is.

Last, but not least, this release allows you to define an env. variable
called JARS_DIR. All .jar files in that directory get added to the classpath.
A minor convenience.

In this release, I just statically compiled each exe separately rather
than creating a DLL with shared code. Using a DLL sometimes causes mysterious
problems which I don't understand and may (or may not) investigate. This
is why the archive file is so much bigger on this version.

Improvements and changes in Version 0.50

Version 0.5 offers a much better solution for the deployment of Java
applications. Executable .jar files a la Java 2 are supported. Also,
a simpler scheme is supported whereby naming the .jar file the same
as its main class makes the archive directly executable. By default,
also, SmartJ will assume that any .jar or .zip archive files in the
same directory as the executable archive are part of the same project,
so it will tack them onto the classpath.

SmartJ will automatically place archive files that are in the same directory
as the executable archive file on the classpath. This provides a convenient
place to put third-party libraries and resources without maintaining an explicit
CLASSPATH environment variable. In fact, there is the further option of
putting them in a subdirectory called "lib" or "libs". Any archive file in a
"lib" or "libs" subdirectory relative to the executable archive file will be
placed on the classpath.

Note also that SmartJ supports the use of executable .jar files with Java 1.1
or Java 1.2. As before, Java 1.1 is the default. You can specify Java 1.2 by
using the -12 command-line option. (At some future point when Java 2 is more
firmly established, I will likely change the default and have it search for a 1.2
runtime by default. In that case, you would need to specify -11 on the
command line to get java 1.1)

Other, minor improvements.

If the .class file you click on corresponds to an Applet, it can be viewed
with SmartJ -- even if the Applet has no main() method and no web page is
set up. SmartJ does this by instantiating a Frame and placing the Applet in
the Frame's client area. Of course, the Applet has no associated AppletStub or
AppletContext, so methods such as getParameter() and getCodeBase() will
just throw a NullPointerException -- as is typical of when you run an Applet
as a standalone application. That limitation notwithstanding, this can still
be a significant convenience, particularly for developers.

The SmartJC utility now allows you to pass through jikes-specific options to the
jikes compilation engine -- assuming that jikes is being used, of course. These
are the options that begin with +. The most commonly desired one is probably +E,
which outputs the error messages in the terser emacs format. This is a
format that emacs (and most other programmer's editors) can parse, thus
allowing you to click on an error message and be taken directly to the
corresponding line in the source file.

Improved the feedback messages you get under some circumstances.


Improvements and changes in Version 0.4x

Introduced support for Java 1.2 and the latest JVM from Microsoft that
supports JNI. The VM to launch with can be chosen via a right-click on the
classfile in the windows shell.

The SmartJC utility now can use the jikes compilation engine from IBM
Alphaworks. This is a separate download. The installation routine now puts
in a key so that you can right-click on a folder icon in the shell and have
it recursively recompile all the java source in there.

Introduced the -p option which causes the execution to pause before exit if
it is running as a console app. This is useful if you launch SmartJ or
SmartJC from the windows shell and it opens a console window. Otherwise,
without -p, the program runs and then immediately closes the console window,
so you don't get to see any error messages.

In Java 1.2, any archive in <javahome>/lib/ext is automatically added to
the classpath by default. SmartJ mimics this behavior even if you are using
a 1.1 runtime. Also, as before, any jar or zip files in <javahome>/lib are
automatically tacked onto your classpath. This gives you another
convenient place to drop a java archive and make sure it is always
on your classpath (somewhat analogous to the C:\windows\system as a place
to drop .dll's). <javahome>/classes is also put on the classpath so this
provides a place to put commonly used .class files.

SmartJ is now open source. A couple of people expressed interest in
hacking the code and I saw no reason not to let them do so. I have nothing
very organized right now. I am working up a (hopefully) enticing
website. Meanwhile, if you are interested, drop me an email and I'll drop
you the Object Pascal source.

Improvements and changes in Version 0.3x

Now includes something of an install program. The setup.exe
copies the program files to your Windows directory. (That seems as good as
any a place to put the files, simply to make sure that they are on the
system PATH.) The setup program then sets up the registry key that makes
.class files double-clickable.

Introduced SmartJC.exe, which is a replacement for Javac.
Aside from this (which is important and IMO justifies the version number
change) there is no significant change to SmartJ.exe or SmartJW.exe.

SmartJC is a drop-in replacement for Javac with the following extra
features:

(1) SmartJC takes a directory as an argument, and will recompile all
    out-of-date source files in the entire hierarchy.

(2) SmartJC checks whether a file is newer than its corresponding .class
    file in determining whether to recompile. The -f option turns off that
    check.

(3) Like its companion utilities, SmartJ and SmartJW, SmartJC also does a
    "sanity" check of the Classpath before launching the JVM. Basically, it
    looks in your source files to see what the package name is and sets up
    the classpath in a way that makes sense. If this is impossible, it warns you.

Improvements in Version 0.2x

SmartJ now uses a DLL, jlaunch.dll.
SmartJ.exe and SmartJW.exe are just stubs that call functions in the DLL.
This makes the distribution smaller.

Fixed certain problems in the processing of command-line
arguments. The previous version did not expand wildcards.

It now understands all the command-line options that JRE.EXE
uses. As before, SmartJ tells you which JDK it is using and what classpath.
This is the default behavior. However, there is now a -Q option that turns that off.

SmartJ spits out the command-line options if invoked with no parameters.

Notes:

SmartJ can be used as a drop-in replacement of the launchers in the Sun
JDK and JRE. With the following caveats:

1. Currently, SmartJ only works with Sun's JDK or JRE 1.1.x or the most
recent Microsoft JVM that supports JNI. (To use the compiler utility,
SmartJC, you need the Sun JDK, since the JRE does not include a compiler.
SmartJ will also use the IBM Jikes compilation engine which is a
separate download.)

2. SmartJ is Win32 specific.

3. SmartJ has a behavior that is different from the Sun JDK in that the
current working directory ALWAYS has first crack. What that means is
that if you go:

smartj foo

and there is a foo.class in your current directory, SmartJ will do its
best to launch that class. If necessary, it will set up the classpath so
as to make that possible. This differs from the Sun JDK behavior. If, for
example, your classpath is defined as:

C:\jdk\lib\classes.zip;C:\myclasses;.

then the Sun JDK will launch a foo.class in C:\myclasses rather than the
one in the current working directory.

The Sun JDK follows a UNIX tradition in which the current working
directory is NOT on the system path by default. I feel that this, along
with the case-sensitive nature of class names, has been the cause of much
confusion, since in DOS/Windows, the current working directory ALWAYS
takes precedence over the system path and the command shell is never picky
about lower/upper case. Unlike Unix, Windows will only look for an executable
on the path if it can't find it in the current directory.

Basically, in these regards, the JRE/JDK launchers (for better or worse)
follow a Unix tradition, while SmartJ is consistent with the DOS/Windows
tradition -- also for better or worse.

Further Notes:

SmartJ has various places for you to drop third-party libraries and
resources. All archive files in the application's base path are
added to the classpath. If your application's base path has a
subdirectory called "lib" or "libs" all archive files in there
are added to the classpath when you launch the application.

For resources that should be available globally, note that SmartJ
automatically puts <javahome>\classes on the classpath,
as well as any .jar or .zip file that is in <javahome>\lib or
<javahome>\lib\ext. This gives you a convenient place to put
any class files or jar files that you use frequently without
having to maintain a classpath.

(Since SmartJ automatically adds any .zip or .jar file it finds in
<javahome>\lib to the classpath, I chose to have it search for
the plugin first -- if there is no JAVAI.DLL on the system path.
If the plugin is installed, Swingall.jar is in the <javahome>\lib directory
automatically and is thus automatically on the classpath.

If you have any questions, do not hesitate to contact me at
[e-mail]. Check back frequently at:

http://www.bigfoot.com/~crystalline.solutions

for the most up-to-date version of SmartJ.

SmartJ License: Free.

You may use SmartJ yourself or redistribute SmartJ to deploy your java application,
commercial or otherwise, as long as you:

(1) leave the banner text (console mode) and/or about box
(GUI mode) intact that indicates the author and the URL where
the user may obtain the latest version of SmartJ. That URL is currently:

http://www.bigfoot.com/~crystalline.solutions.

(2) Include this readme file.

(SmartJ is copyright material and your use of it implies acceptance of the
above conditions.)

My Consulting Services:
(An attempt to NOT be completely non-profit. :-)

SmartJ is free and you can use it freely under the very liberal terms
stated above. However, my consulting services are not free. On the one hand, I am
very interested in suggestions and bug reports and even questions that can
help me improve the product and documentation. On the other hand, if you do
want fairly extensive help that is related to deploying your commercial
Java application, where some custom version of SmartJ seems like a good
solution, feel free to contact me. Note also that SmartJ is open source.
If you can adapt the source code to your purposes, that is fine. However,
buying a few hours of my consulting time might be your most cost-effective
option.

Jonathan Revusky, June 25, 1999.